软件项目是资助和组织软件开发的一种流行方式。它们将工作组织成临时的、仅构建的团队，并通过商业案例中预测的特定收益获得资金。而产品模式则使用持久的、构思-构建-运行的团队来处理持续的业务问题。产品模式允许团队快速调整方向，缩短端到端周期时间，并允许通过使用短周期迭代来验证实际收益，同时保持软件的架构完整性以保持其长期有效性。

当面临替换现有软件系统的需求时，组织通常会陷入技术替换半途而废的循环。我们的经验教会了我们一系列模式，可以让我们打破这种循环，这些模式依赖于：刻意识别替换遗留软件的预期结果，将这种替换分解成多个部分，逐步交付这些部分，以及改变组织文化以认识到变化是不变的现实。

为了有效利用技术，我们需要将我们的技术思维与基础业务计划保持一致。技术战略可以推动这种一致性，前提是它能够恰当地整合业务和技术。我们开发了一个概念框架来帮助我们进行这种战略思考，该框架基于识别战略举措的共同方面，引导我们确定了 11 个普遍的战略方向。对于每个方向，我们都概述了它们提出的关键业务问题，以及我们需要进行的调查以探索技术影响。我们发现，这个框架不仅可以带来更有效的技术战略，还可以让技术为业务思考提供信息，开发新的收入来源。

良好的技术设计决策非常依赖于环境。定期围绕共同目标开展工作的团队能够定期沟通并快速协商变更。这些团队展现出强大的协作力，并且可以制定技术和设计决策来利用这种力量。当我们放大到更大的组织时，在独立工作且协作频率较低的团队和部门之间存在着越来越弱的力量。认识到这些强弱力量的差异，我们可以为每个级别做出更好的决策并提供更好的指导，从而使团队能够更快地行动。

架构不一定是自上而下的独白，也不一定是来自少数集中管理者的想法和言论。本文描述了另一种架构方式：作为一系列对话，由分散和授权的决策技术驱动，并由四种学习和协调机制支持：决策记录、咨询论坛、团队原则和技术雷达。

模块化架构可以改进软件交付吗？是的！- 但有一些需要注意的地方。本文描述了一家企业为了缓解日益增长的痛苦而着手将其架构转变为更加模块化的架构的过程。他们发现，模块化是一个多方面的解决方案，它超越了架构本身，延伸到了业务沟通线、团队拓扑结构和有效的开发者体验。通过密切关注这些因素，该企业能够在其移动应用程序的交付性能方面取得显著提升。

Xapo 成立之初是一家比特币服务提供商，后来发展成为一家在线银行。在转型过程中，它需要重新评估其软件资产，并建立架构能力来指导其未来发展。它借鉴了领域驱动设计、团队拓扑结构和架构咨询流程的理念，开发了架构咨询论坛。这使得其软件交付团队更加协调一致，并制定了连贯的技术战略。

商业集成工具已经出现了二十多年，但几乎没有关于何时以及如何使用它们的总体架构原则。在本文中，我认为“购买”决策机制导致我们夸大了此类工具的价值主张，通常导致强制使用某种集成工具而不是通用语言。我声称，此类工具在一个将集成主要视为连接系统的世界中蓬勃发展，但数字化组织已经将集成重新定义为主要是在数字功能前面放置清晰的接口，强调功能而不是系统。最后，我列出了一些现代集成视图背后的关键原则，并声称最好使用通用语言来管理它们，重新定位商业集成工具的主要价值主张，使其转向简化战术实施问题。

基础设施平台团队通过使用弹性解决方案解决常见的产品和非功能性需求，使组织能够扩展交付。这使得其他团队能够专注于构建自己的东西并为其用户创造价值。但没有人说过构建可扩展的平台很容易……在本文中，Poppy 和 Chris 探讨了 7 个可以帮助您正确构建事物的关键原则。剧透：不要跳过战略、用户体验和研究。

在 DevOps 文化中集成必要的安全控制和审计功能以满足合规性要求可以利用 CI/CD 管道自动化，但在组织扩展时会带来独特的挑战。了解所选实施方案带来的二阶影响和意外后果是构建有效、安全和可扩展解决方案的关键。

当一个组织采用敏捷思维方式时，企业架构并不会消失，但企业架构师的角色会发生变化。企业架构师不再做出选择，而是帮助其他人做出正确的选择，然后传播这些信息。企业架构师仍然需要形成愿景，但随后需要在团队之间架起桥梁，以建立学习型社区。这将使团队能够探索新方法并相互学习，而企业架构师则是这种成长中的合作伙伴。

我们和我们的同事经常被要求为客户执行架构评估。当我们这样做时，参与这些系统的架构师会谈论这些系统的性能、它们对故障的弹性，以及它们是如何设计成易于演进以支持新功能的。然而，很少被提及的是，不同的系统如何为业务价值做出贡献，以及这种价值如何与其他架构属性相互作用。

许多大型组织发现他们的 IT 引擎与行政顶层之间隔着许多层楼，这也将业务和数字战略与执行这些战略的重要工作分离开来。架构师的主要作用是在顶层和机房之间乘坐电梯，在需要支持这些数字工作的地方停下来：自动化软件制造、最大限度地减少前期决策，以及随着技术发展影响组织。

很大一部分架构精力都花在了减少或避免锁定上。这是一个相当崇高的目标：架构的目的是为我们提供选择，而锁定则恰恰相反。然而，锁定并不是一个简单的真假问题：避免被锁定在一个方面通常会将您锁定在另一个方面。此外，一些流行的观点，例如开源可以自动消除锁定，结果证明并非完全正确。是时候仔细看看锁定了，这样你就不会为了避免锁定而把自己锁起来！

大多数内部 REST API 都是为单个集成点专门构建的一次性 API。在本文中，我将讨论非公共 API 的约束和灵活性，以及在多个团队之间进行大规模 RESTful 集成所获得的经验教训。

在理想状态下，产品模式组织由松散耦合、自主的团队组成，这些团队对明确和未明确的用户需求做出快速响应。然而，有时会出现需要多个团队协调才能应对的机会。如果管理不当，结果将导致收入损失、客户不满意和团队能力浪费。我们将响应这些机会的组织计划称为项目。在本文中，我们将通过一个失败项目的例子，分享我们在产品模式组织中管理项目的经验。

当客户公司购买软件产品时，他们通常需要熟练的员工来安装它们。这些员工通常由服务提供商公司提供，因为软件产品供应商认为建立自己的服务部门没有商业意义。客户需要了解产品供应商和服务提供商之间的关系，并应要求与其合作的人员对这种关系保持透明。随着云供应商的兴起，这些合作伙伴关系日益突出，这种透明度也变得越来越重要。

企业架构团队经常与日常开发脱节。这会导致他们对开发工作的了解过时，而开发团队也没有从公司全局的角度考虑问题。我的同事（Thoughtworks 首席技术官）Rebecca 经常看到这种情况发生，她认为企业架构师可以通过加入开发团队来提高效率。

在 2008 年旧金山 QCon 大会上，Rebecca Parsons 和我发表了一个关于敏捷方法如何与企业架构团队合作的演讲。目前，敏捷项目团队和架构团队之间存在很多不信任和冲突。我们深入探讨了造成这种情况的原因，并探索了这些团队可以合作的方式。

最近，我的同事 Neal Ford、Rebecca Parsons 和 Pat Kua 写了一本名为“构建演进式架构”的书。我很荣幸他们邀请我为这本书写序言。

许多企业正在投资于他们的下一代数据湖，希望大规模地实现数据民主化，以提供业务洞察力并最终做出自动化的智能决策。基于数据湖架构的数据平台具有常见的故障模式，这些模式会导致大规模无法兑现承诺。为了解决这些故障模式，我们需要从湖泊或其前身数据仓库的集中式范式转变。我们需要转向一种借鉴现代分布式架构的范式：将域视为首要关注点，应用平台思维来创建自助服务数据基础架构，并将数据视为产品。

康威定律（由 Melvin Conway 于 1968 年提出）指出，系统的设计受其设计者的沟通模式的限制。Birgitta、Mike、James 和我讨论了这一原则的含义，以及我们在职业生涯中是如何看到它发挥作用的。我们讨论了它对微服务概念的影响、与业务能力保持一致的重要性，以及逆康威策略的作用。

软件开发中尚未解决的问题之一是确定一段软件的边界是什么。（浏览器是操作系统的一部分吗？）许多面向服务架构的支持者认为应用程序正在消失——因此未来的企业软件开发将是关于将服务组装在一起。

我认为应用程序不会消失，原因与应用程序边界如此难以划定的原因相同。本质上，应用程序是社会建构的

几乎所有我喜欢的软件架构从业者都对该领域中的任何一般性定律深表怀疑。好的软件架构是非常特定于上下文的，它分析了在各种环境中以不同方式解决的权衡问题。但如果说有一件事他们都同意，那就是康威定律的重要性和力量。它足够重要，可以影响我遇到的每一个系统，而且足够强大，如果你试图与之抗衡，你注定会失败。

在每个正常规模的团队中，将任何技术类别的备选方案限制为三个。它们是：当前合理的默认方案、我们正在试验的方案以及我们讨厌并希望淘汰的方案。

就在最近，我在亚马逊上收到了一些关于《企业应用程序架构模式》的差评，因为书中没有关于企业架构的内容。当然，这有一个很好的理由——这本书是关于企业应用程序架构的，即如何设计企业应用程序。企业架构是一个不同的主题，它是关于如何将企业中的多个应用程序组织成一个 cohérent 的整体。

每当 Thoughtworks 让我在客户面前轻率行事时，我一定会被问到的一个问题是“你对 SOA（面向服务的架构）有什么看法？”这是一个几乎无法回答的问题，因为 SOA 对不同的人意味着不同的东西。

任何大型软件工作，例如大型公司的软件资产，都需要很多人——每当你有很多人时，你都必须弄清楚如何将他们分成有效的团队。组建以业务能力为中心的团队有助于软件工作快速响应客户的需求，但所需技能的范围通常会让这些团队不堪重负。团队拓扑是由 Matthew Skelton 和 Manuel Pais 开发的一种用于描述软件开发团队组织的模型。它定义了四种形式的团队和三种团队交互模式。该模型鼓励健康的互动，使以业务能力为中心的团队能够在其提供稳定价值流的任务中蓬勃发展。